This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 



BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the 
original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 

• BLACK BORDERS 

• TEXT CUT OFF AT TOP, BOTTOM OR SIDES 

• FADED TEXT 

• ILLEGIBLE TEXT 

• SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 

• GRAY SCALE DOCUMENTS 



IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
please do not report the images to the 
Image Problems Mailbox. 



iMIIinillMIIIIIIHIIII 

US005781908A 

United States Patent [19] [Hj Patent Number: 5,781^8 

Williams et al. [45j Date of Patent: Jul. 14, 1998 



[54] FILE DATA SYNCHRONIZER IN A 
DISTRffiUTED DATA COMPUTER 
NETWORK 

[75] Inventors: Thomas IL Williams* Unlet on. Colo.; 

Charles J. Cape, Stroogsville, Ohio; 
Richard T. Jackson. Castle Rock. 
Colo. 

[73] AssigDce: J J). Edwards World Source 
Company, Denver. Colo. 

[21] AppL No.: 575,732 
[22] Filed: Dec IS. 1995 

[51] Int. a.* G06F17/#0 

[52] U.S. CL 707/lW; 707/203; 707/10 

[58] Fidd ofSeardi 395/601. 614; 

340/825.02, 825.05; 380/4. 25. 30; 707/1-10. 

100-104. 200-206 

[56] References Cited 

U.S. PATENT DOOmENTS 

4.007.450 2/1977 Haibtetal. 34(V1723 

4,432,057 2^984 Daniefl et al. 364/300 

4^87^04 12/19S9 Jolnson et aj 364/200 

4^97,781 1/1990 Chang ctal. 364/200 

5.175,851 12/1992 Jobison ct tl 39V600 

5,218,713 6/1993 Hammer etal. 395/800 

5.226.159 7/1993 Hensonelal 395/650 



5.293,487 3/1994 Russo et al „.» 395/200 

5.305,440 4/1994 Morgan et al. 39V200 

533U15 7/1994 Crosctto „ 340/825.02 

5,537,645 7/1996 Heoson ct al 395/650 

OTHER PUBLICAnONS 

"ApplicatioD System/400. System Concepts. Version 2**. 
IBM Corp. publication GC41-9802-01. Second Edition 
(Jun. 1992). pp. 4-11 through 4-14. 
Sidhu, Gursharan S.. Andrews, Richard K, and Oppenhe- 
imcr. Alan B.. "Inside AppleTalk**, Addison-Wesley Put>- 
lishing Company. Inc., Mar. 1989, pp. 13-1 through 13-46. 

Primary Examiner— Thomas G. Black 
Assistant Examine r— David Yiuk Jung 
Attorney, Agent, or Firm — James R. Young 



[57] 



ABSTRACT 



In a computer network comprised of multiple nodes spread 
across different geographic locations and connected through 
a communication system, a Distributed Data Synchronizer 
(DDS) syndironizes files across the network so that user 
applications ninning at the various nodes can share common 
databases of information. In a preferred embodiment, rather 
than store master fdcs at a server node, each node stores a 
master copy locally in a disk drive. When a user application 
modifies one of the local files, the DDS communicates the 
update to the appropriate remote nodes under the control of 
a user defined script file. 

25 Clahns, 8 Drawing Sheets 
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r Global V 
FileDataRec *DataRec 

ProcessList(ScriptList *List) 

ScriplRec *CijrRec 
Integer i =0 

CurRec - List->Get First 
While CurRec 

Switch{CurRec.Command) 
{ 

case START: 

lnlerProcessCall(CurRec.Param 1 ) 
break 

case END: 

lnterProcessCa[l(CurRec.Param1) 
break 

case READ: 

DataRec = GurRec.Param1->ReadRecord 
break 

case WRITE: 

CurRecParam1->WriteComm{DataRec, CurRec. Param2) 
break 

case PROC: 

lnterProcessCall(CurRecParam1, DataRec, CurRec.Param2) 
break 

} 

If CollectHistory 

DetailFife->WRiteRecord(CurRec,l) 

i = l+1 

CurRec = List->GetNexl 



FIG. 8 
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FILE DATA SYNCHRONIZER IN A 
DISTRIBUTED DATA COMPUTER 
NETWORK 

FIELD OF THE INVENTION 
The present iovcotion relates to distributed data process- 
ing in a computer network, particularly Xo a distributed data 
syndiroDlzer for synchronizing data file records across a 
plurality of netwoilc nodes. 

BACKGROUND OF THE INVENTION 

In a computer network comprised of multiple nodes 
spread across different geographic locations and connected 
through a communication system, it is often necessary for 
applications running concurrently aaoss the nodes to share 
access to the same database of ioformaiion. An accounting 
a^Ucation. for exan^le, running at various different nodes 
in the network may operate on the same data base such as a 
genera] ledger. An update to a record in the database at a 
local node must be synchronized or reflected to the other 
remote nodes in the system so that the applications running 
at the different nodes have access to the most recent data. 
Tlie data itself is normally represented as a plurality of 
records in a file stored In a non-volatile storage device such 
as a disk drive. The goal then is to synchronize the content 
of these data files across the various nodes in the computer 
network. 

One method of synchronizing file data aaoss the network 
is to maintain a master file at a server node and send copies 
of the master file to client nodes. After operating on the copy 
of Ac file, the client node transfers the modified copy back 
to the server node where it is used to update the master file. 
Hiis technique is most practical in environments where the 
client nodes do not need to update the master file on the 
server node or in environments where the amount of dau to 
be copied is small and the data is updated infrequently. The 
advantage is that the application on the client node runs 
faster since it has Immediate access to the copy of the master 
file stored locaUy. This technique is less practicaL however, 
in environments where the client nodes need to i^pdate the 
master file on the server node, large amounts of data must be 
copied, aiKi die data is updated frequently. 

For applications where file o^ying is not practical, a 
nKre efficient method allows the client nodes to access die 
records dirccdy from the roasts file through the network. 
Tlus method has an advantage in that the client node 
operates on the actual, current data. Modifications to records 
by the client nodes are reflected immediately oo the master 
file. However, direct access to the master file over the 
network is less desirable where the number of accesses is 
significant and the network latency slows operation of the 
client applications. 

A widely used prior art technique for distributed daU 
processing is described in "Distributed Data Management 
(DDM) User's Guide". August 1990. IBM, SC2 1-9600-2. 
The DDM system disclosed in this work supports both of the 
above tediniques: c(^ying a master file to a client node; and 
direct access to the master file over the network. In both 
methods, the user of the client node creates a DDM file 
which rcprescots the master file stored at the server node. 
Applications running at the client node access the DDM file 
as though it were stored locally. A DDM driver also running 
on the client node intercepts the file access commands and 
performs the requested operations on the master file stored 
at die server node over the network. 

To implement the above copy mediod of distributed data 
management, die user of a DDM system simply executes a 
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copy file command, specifying the DDM file as the source 
file and a local file as the destination file. The DDM driver 
intercq)ts the copy command and copies the master file from 
the server node to the local file at the client node. The client 
5 node application then operates on the local file to avoid the 
latency associated with communicating over the network. At 
a predetermined interval (and usually at night) the local copy 
is transferred back to the server node and used to update the 
master file. After updating the master file, it is again trans- 
ferred back to all the dicnt nodes so thai the client appli- 
cations access the most recent data. As mentioned above, 
transferring entire files between the server and client nodes 
becomes prohibitively inefficient as the amount of data and 
number of nodes increase. 

To decrease the amount of data transferred, the above 
direct access method of distributed data management can be 
in^lemeated by executing read and write commands for 
records of the DDM file. The DDM driver intercqjts the read 
and write commands and performs the operations on the 
master file stored on the server node over the netwoik. As 
previously mentioned, directly accessing the master file over 
the network can slow operation of applications running on 
the client nodes, especially when the number of accesses to 
the database is significant 

25 In addition to streamlining the lUe transfer process, the 
IM'esent invention overcomes significant drawbacks associ- 
ated with the prior art distributed data management tech- 
niques. Specifically, the prior art does not allow any user 
defined processing to occur as a part of the fUe transfer 

2Q i»'ocess. For example, the client node may want to transfer 
only those records that wae naodified, deleted or added to 
the local file in order to minimize the amount of data 
transferred to the server node. This requires temporary files 
and scrub routines in network systems using the prior art 

,5 techniques of distributed data management. 

Normally. nK>difications to datat>ase files are stored as 
records in a local log file (or journal file). In a DDM system 
using the direct access method, a scrub routine reads each 
record from the local log file and updates the DDM file (Le.. 

40 the master file) by writing each record over the network and 
waiting for an acknowledgment. If the DDM system uses the 
copy method, then the local copy of the log file is transferred 
to the server node and stored in a temporary file. A scnib 
routine running on the server node ttien reads each record 

45 from the temporary file and updates the master file. When 
the update is complete, the scrub routine deletes the tem- 
porary file. 

The direct access and copy methods used in the prior ait 
DDM systems are inefiBdent due to the communication 

50 latency and unnecessary number of dau management steps. 
Consequently, the processing necessary for distributed data 
management can quickly saturate the data processor of die 
server node which maintains the integrity of the master 
database files for the entire network. 

55 There is. therefore, a need for an improved apparatus and 
method for distributed data management across multiple 
nodes in a computer network system which allows user 
defined processing to occur concurrent with the fUe transfer 
process so that temporary files and scrub routines are 

£0 obviated Another aspect is to avoid using a server node for 
storing master copies of the database files, thereby alleviat- 
ing the above mentioned saturation problem. A further 
aspect is to provide an integrated user Interface to the 
distributed data management system to allow the user to 

65 specify how the file transfer will occur, including pre- 
processing and post-processing of data records, and batch 
transfers to multiple nodes. 
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SUMMARY OF THE IhfVENTION description is not to be taken in a Umiting sense but is made 

In a computer network comprised of multiple nodes merely for the purpose of describing the general principles 

spread across different geographic locations and connected invcDtion. The scope of the invention should be 

through a communication systcnL a Distributed Data Syn- determined by referencing the appended claims, 

chronizer (DDS) syndiironizes files across the network so 5 

that user applications running at the various XK>des can share Overview 

common databases of informatioii. In .a preferred j^q^ j ^^ows a prior art implementaUon for distributed 

eii^odimen , rather than store master files at * ^^«v«^ oode. management iia compuS^netwak 17 whid, may be 

each node stores a master copy locally in a disk drive. When i i ^ i ^^.^ * , *Tii*Mi ii«jr 

a user appUcaUon modifies^ of the local files, the DDS ,o 'J^^'" ^Zv^ % ""^T^ ""T"^ 

commuZ^cs the update to the approj^ate remote nodes ^"^f ^ ^ P^"^^ connected by any suffiaent 

under the control of a user defined script file. "^^^ oommuoicaUons as is well known by those 

The script file contains multiple script records where each '^f^ ^5 *^ ^ E^chnode comprises a conventional video 

script record contains a command and optional parameters. ^^^^ ? inXtrf^t. a convenUonal disk dnve 4 for 

nje script commands, for example, might read a record from ^^^8 daU m the form of records of a file, convenaonal 

a journal file, process the journal record to extract an "after" faiidom access memory (RAM) <. and a conventional data 

image record, and transfer the "after" image record to die processor 8. The data processor 8 retrieves from RAM 6 and 

appropriate remote nodes. DDS programs nmning on the executes user applications 10. a standard network commu- 

remote nodes receive the "after*' image recced and use it to oicatioo process 12. and a distributed data manager (DDM) 

update their local copies of the associated database files. Th^ conventional DDM 14 of FIG. 1 operates between 

One of the script commands caUs a user defined record ^ aj^cadons 10 and the local disk drive 4 by 

processing procedure in wdcr to pre cr post process records intercepting user application calls to modify a file. If a file 

as part of the synchronizing process. In the above exanqile. *^ation involves a remote file stored at a remote node, the 

a user defined procedure executes the step of extracting the 1^ requested <^ation using the 

"after" image from die journal record. Inter-process coni- communication process 12. The DDM 14 operates transpar- 

munications in^)lemcnts tiic call to user defined procedures *° applications; that is, the user applications 

in order to provide maximum user control over the synchro- standard file management calls as if the file was sUh^ 

nizing process without having to rtxranpilc or re-link tbc °° drive 4. However, die conventional DDM 

DDS program. 1^ docs not provide any user defined pre or post processing 

The user configures the DDS program by creating and 30 ^^"^ as pact of the file transfer process, 

editing script files in a script editoc: A status menu displays ^ illustrates the distributed data synchronizer (DDS) 

information related to the status of DDS jobs executing the the present invention operating in a computer network 

script files. Multiple script files may execute concurrentiy to similar to FIG. 1 excqH diat tiic DDS 16 does not intcrcqjt 

simultaneously synchronize a plurality of coxrcspondtng application calls to modify a file, and it allows user 

database files. 3^ defined pre aitd post processing of records as an integrated 

RRmFnPQrHTPTTnisjnPTHP ncAwmr^ part of tiie file syochioDizing process. The DDS 16 is 

BRIEF DESCRIPTION OF THE DRAWINGS configured to continuously monitor files stored on the local 

The foregoing, and other features and objects of the diskdrive4tfaatmay be updated by the user applications If. 

present invention and the manner of attaining them will If the status of a file changes because a user ^iplication 

become more apparent, and the invention itself will be best modifies or adds a record to the file, the DDS 16 reads that 

understood by reference to die following description of a record, performs user specified |»c-processing, and transfers 

preferred embodiment taken in con>inction with die accom- the record to a remote node over the network 17. When the 

panying drawings. \^crein: remote node receives the record, the DDS 16 running on the 

FIG. 1 shows a prior art method for implementing dis- remote node performs user specified post-processing and 

tributed data management over a con^Mitcr network com- updates the coiresponding file accordingly, 

prised of several nodes located at various geographic in this manner, the user apptications 10 running at the 

locations, wherein each node cora^wises a hard drive, a video various nodes in tfie network can share common databases 

monitor, random access memory, and a daU processor for of information. Rirthcxmore. Uicrc is 00 server node fix 

executing a pricff art DDM program; stwing master a^es of files. Instead, each node stores a 

FIG. 2 shows die computa network executing the dis- ^ master copy of tiie files that die node's user plications 

tributed daU synchronizer (DDS) of the ptcscoX invention; require. If a shared file is updated by a node, then the 

FIG. 3 illustrates a data flow diagram of the DDS; modified record is transferred from that node to the otho* 

FIG. 4 shows a menu for creating DDS jobs to handle file renwtc nodes sharing die same file. The other nodes then use 

data transfa between the nodes of the network; modified record to update dicir master copy of die file. 

FIG. 5 is a script editor menu for creating user defined 55 TWsimplementationof distributed data management has the 

data processing executed by the DDS; benefit of immediate access to local files and avoids saiu- 

FIG. 6 is a status menu for displaying status related to '^^^ * communication and file data 

operation of die DDS jobs; processing. 

FIG. 7 illustrates an execution flow diagram <rf the DDS; Distributed Data Synchronizer 

and 60 

FIG. 8 is pscudo code depicting an in^cmcntation of die Operation of die present invention is understood with 

pDS^ reference now to FIG. 3 which shows a daU flow diagram 

r.«o^r«^^v, ^ r^™- ^ As shown in FIG. 3. die DDS 16 comprises 

DESCRiniON W Tlffi PR^^ a DDS driver 18, a file rcada 2#. a record processor 3. and 

EMBODIMENT a file writer 24, 

The following description is of die best prcscntiy con- The file reader 20 reads itcords from three types of files: 

tcmplated mode of carrying out the present invention. This journals 25, data queues (DTAQ) 26, and database files (DB 
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FILE) 28. JournAling is a wcU knowo method for logging 
changes made to a database file by storiAg event records In 
a journal Ale. For example, a journal entry might contain a 
copy of a datatiasc record before and after being modified 
along with a system and program identifier to identify the 
system and program making the modiiication. Journal files 
provide an efficient method for mooitoring modifications to 
database files and simplifying distributed data management 
as will be appreciated in the discussion that follows, 

A data queue (DTAQ) 26 is a special type of file noimally 
in^)lemented as a first-io first-out (FIFO) queue of records. 
In network commuDicatioas. for ala^^>le. a data queue file 
temporarily stores records received from remote nodes until 
read by an application nmniog on the local node. When an 
application reads a record, that record Is Immediately deleted 
from the data queue file. Data queue files provide an efiEicieot 
and robust method for inter-process communications since 
the records are teii^x>rarily stored in the non-volatile storage 
device {It., the disk drive) until read by the receiving 
application. 

The file writer 24 writes records to data queue files 26, 
data communication queue files 30, and data base files 28. A 
data communication queue file 30 is associated with the 
communication process responsible for transfening records 
to remote nodes. When the DDS 16 of the present inventioo 
needs to transfer an updated record to a remote node, the 
record is written to. and tcn^xirarily stored in. an appropriate 
data communication queue file 30 until transferred by the 
communications process 12 of FIG. 2 to & remote node. 

In the prefecred embodiment the DDS 16 is implemented 
as a device driver wtilch runs continuously along with user 
applications or during user specified intervals (e.g.. at night). 
The DDS driver IS continuously sends read requests 32 to 
the file reader 20 which returns records 34 modified or added 
by die user applications 10. When a reccrd 34 is returned 
from the file reader 20. the DDS driver 18 passes it to a user 
defined rccca-d processor 22 for preprocessing according to 
a user defined criteria. The record processor 22 returns a 
modified record 36 to the DDS driver 18 for transfer to a usex 
specified remote node. The record processor 22 mig^t deter- 
mine that the record should be excluded fi^om the synchro- 
DizatioD process. In (his instance, the record processor 22 
will return a NULL record 36 so that nothing is transfarcd. 

To transfer the modified record 36 to a remote node, the 
DDS driver 18 sends a write request 38 and the nkodified 
record 36 to the file writer 24. The write request 38 com- 
prises the nanoe of a data communication queue file (DCQ) 
30 associated with a remote node and a name of a destination 
data queue file (DTAQ) 26 fix staring the modified record 
when received. The file writer 24 writes the modified record 
36 to the data conomunication queue file (DCQ) 30 so that 
the communicatioa process 12 can retrieve and transfers it to 
the remote node. 

When the record is received, a DDS 16 ruxming on the 
remote node reads the record 34 from the destination data 
queue file (DTAQ) 26 using the file reader 20 as previously 
described, performs user defined post-processing 22 of the 
record 34. and updates the appropriate database file 28 
accordingly. 

As an exan^le illustrating the utility of the present 
invention, consider an address book database file containing 
address records for a particular group of people where 
modifications to the address book can be made by user 
applications running at various nodes across the network. 
When an update to the address book is made at a given node, 
an event record is written to a corresponding journal file to 
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log the modification. The journal event record contains a 
"before** and "after** image of the updated record along with 
the system and program name making the modification. This 
modification to the address book needs to t>e reflected in the 
5 address t>ook files stored at the remote nodes of the network. 
The DDS 16 effectuates the global update to the address 
book files across the network try performing the following 
steps: 

(1) reading 20 the local journal event record 34; 
10 (2) pre-processing 22 the event record 34 to extract an 
"after** image record and program name that made the 
modification and storing this information in a source 
record 36; 

(3) writing the source record 36 to a data communication 
15 queue file (DCQ) 30 associated with a remote node so that 

the communicatioD process 12 will transfer the source 
record 34 to the remote node where it is stored in a user 
specified destination data queue (DTACJ) 26; 

(4) reading the source record 34 from the destination data 
20 queue (DTAQ) 26 at the remote node; and 

(5) post-processing 22 the source record 34 to update the 
address book of the rcnacAt node. 

Notice that the last step, updating the address book of the 
remote node, will generate a journal event at the remote 

25 Dode. This will cause the DDS 16 of the remote node to 
initiate the same synchronization process resulting in an 
infinite synchronization loop between the nodes. To avoid 
this problem, the user defined pre-processing of step (2) 
looks at the program name that made the modificatioD to 

^ address book file. If the name of the modifying program is 
the DDS 16 program, then the after image record is not 
transferred to the remote nodes. 

As the DDS 16 of the present invention executes the 
distributed data management process as described above, it 

35 periodically updates two files: a job status file 40 and a job 
dctaU file 42. The DDS 16 writes a status record 44 to the job 
status file 40 to provide the end user with information related 
to its operation: whether it is running or terminated; the 
number of records read 46 by the file reader 20; and the 

40 number of records transferred 47 by the comimjnication 
process 12. The DDS 16 also writes a detail record 48 to the 
job detail file 42 every time it executes a step in the process 
(Le.. a script command described below). The detail record 
48 comprises information related to a current execution step 

45 including the current function called and parameters passed 
This information can then be used to trouUeshoot problems 
associated with running the DDS 16. 

Unlike prior art implementations of distributed data 
management, In the present invention the user exercises 

50 con^lcte control over die process by programming the DDS 
16 with user defined scripts. The DDS 16 reads a user 
created script file 50 and executes die script commands 
contained therein. A user interface of the present invention 
provides a script editor which allows the user to create and 

55 edit the DDS script files 50 as described in die section that 
foUows. 

User Interface 

FIG. 4 shows the user interface of the present invention 
60 for aeating, editing, and running DDS jobs. A DDS job 
comprises: a Job Name 52 which identifies an associated 
script file; a Job Title 54 which descrit>es the job; a User ID 
56 and an Update Date 58 for system administration. A 
Driver ID 60 field identifies the name of the DDS 16 
65 program executed by the operating system when a job is 
started. There may be several user defined DDS jobs running 
concurrently (i.e., several copies of (he DDS 16 program 
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executing an associated script file) where each job is respon- 
sible for syocbroaizing a particular file across the network. 

The available user options listed at the bottom of the menu 
in FIG. 4 include: running a job 62; editing a job script file 
64; creating a new job (i.c.. a new script file) 66; and deleting 
an existing job 68. To execute an option, the user enters a 
coiTcspooding number in an OP field 76 located at the left 
side of the Job Name 51 To create a new job. the user enters 
a 3 in the OP field 79 at an empty line in order to display the 
DDS script editor as shown in FIG. 5. 

Once in the script editor of FIG. 5, the user enters a Job 
Name 72. a Job Title 74. a brief Description 76, and whether 
the DDS will collect the job histoiy 78 (Lc., save detail 
records 48 in the job detail file 42). Each record of the script 
file contains: 

(a) a Sequence Number 86 which identifies the order of 
cxcctition; 

(b) a System Name 82 which identifies the data processor 8 
that will execute the scxipC conunand; 

(c) a Script Veib 84 which identifies the function executed; 

(d) a first and second Type parameter 86,88 which identiiy 
an object type associated with the Script Verb 84; and 

(c) a first and second Value parameter 90.92 which identify 

an object value associated with the Script Verb 84. 
Hie user edits a script record by typing over entries in a field 
or creates a new script record by filling in the fields of a 
blank line. 

The following is a descripdon of the Script Verbs 84 
available to the user 

START accepts a first Type 86 of •PGM and the name of a 
user initialization procedure for a first Value 9#. The 
START verb executes the user procedure at the start of the 
job in order to initialize the DDS program 16. There can 
be zero to many SIART statements in a scxipC 

READ Accepts a firsiTVP* W of ♦JRN, •DTAQ or •DCQ 
file and the name of a file for a first Value 9t. The READ 
verb reads a record from the specified file if a record is 
available. There can only be one READ statement in a 
scripc 

WRITE accqKs a first l^pe 86 <^ ♦JRN. •DTAQ or ♦DCQ 
file and Che name of a file for a first Value 9#. If the first 
Type 86 is ♦JRN or •DTAQ, then the second T^pe 88 and 
second Value 92 arc blank and WRITE verb simply writes 
the cunrent record to the specified file. If the first Type 86 
is a ♦DCQ (data communicatioo queue), then the second 
"Type 88 is a ♦ DTAQ and die second Value 92 specifies the 
name of the destination data queue. The WRITE verb 
writes the current file to the specified data cotmmunication 
queue and. when received by the remote node, the record 
is stored in the specified data queue. There must be one, 
and there may be many WRITE statements in a script 

PROC accepts a first Type 86 of ♦PGM and die name of a 
user defined record processing procedure 22 (FIG. 2) for 
a first Value 9t. The PROC verb calls the spedfied record 
processing procedure 22 and passes the cuxrent record as 
a parameter. There can be zero to many PRCX: statements 
in a script 

END accepts a first lype 86 of 'PC^ and the name of a user 
tennination procedure for a first Value 9f . The END verb 
calls the user termination procedure when the job is 
ended. There can be zero to many END statements in a 
5cr^>t 

The example DDS Job of FIG. 5 sends changes to a local 
address book file from a oode named JDED to a node named 
JDE?C Notice that the script contains all of the conunands 
necessary for both die JDED node and the JDEX node to 
carry out the file update. Both nodes run the sanoc job and 
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execute the same script file, but each node only executes 
those records with a System Name 82 matching the node's 
name. For example, the JDEX node would execute the 
records with the sequence nunit)er5 26, 60. and 86. Storing 
5 the script commands executed by both nodes in one file 
simplifies writing the script and reduces the number of 
progranuning errors. 

When the job of FIG. 5 is started by the user, the DDS 
calls a user defined program P84INTT at both nodes to 
10 initialize the DDS process. Changes to die address book arc 
stored in a journal file ('JRN) named POlOl in the local disk 
drive connected to node JDED. The DDS executing on the 
JDED node reads a journal record and passes it to a user 
defined pre record processor P840101 which extracts die 
15 "after** image fi-om the journal record and returns it in a 
modified record. TTicn the DDS writes the modified record 
to a data oomnuiiucatioas queue (♦DCQ) named JDEX and 
specifies a data queue F0101„O for storing the modified 
record when received by die JDEX node. The DDS running 
20 on the JDEX node reads the modified record from ihc data 
queue F0101_O and transfer it to a user defined post record 
processor P840102 which updates die copy of die address 
book stored at the JDEX node. When die user terminates the 
job. die DDS running at both nodes executes a user defined 
25 END program P84CLOSE to conclude die DDS file transfer. 
The START and END script commands arc executed once 
at the beginning and end oi the job. respectively. The 
commands between the START and END are executed 
continuously in a loop until die user terminates the job. If the 
30 end of the journal file is reached, then the DDS singly waits 
for further journal records to be added. If the Collect Job 
History flag is set to Y (yes), then at eadi step in the 
execution sequence a detaU record 48 is written to job 
dctaU file 42. A job status record 44 is also periodically 
35 written to the job status file 4^ to provide die user with 
information related to the job. 

The DDS job of FIG. 5 illustrates how to transfer updates 
to an address book file stored at node JDED to an address 
book file stored at node JDEX. Batch transfer to multiple 
AO nodes is accomplished by duplicating the script commands 
for each renkote node. This allows the user to control which 
codes receive updates, diereby dividing the network into 
customized subgroups according to the needs of the user. 
FIG. 6 is a job status menu di^layed to the user which 
45 contains the job status information. Included in the job status 
is a list of the Job Names 94. Job Descriptions 96. Read 
Count 98. Transfer (Xfr) Count IM. Date 102 and Time IM. 
and a Condition 1#6 (Active or Terminated). The user enters 
a number in an OP field 168 to start or end a corresponding 
50 job. The Read Count 98 displays the number of records 
READ by die job since the jbb started, and the Xfr Count 
106 contains the number of records suoccssfiiUy transferred 
to the remote nodes. The Date It2 and Hme IM fields 
contain the date and time the job was started if the job is 
55 Active, and if Terminated, the date and time the job was 
ended by the user. 

Script Processing 

Referring now to FIG. 7. shown is an execution flow chart 
60 for the DDS 16 program according to the present invention. 
When the user starts a DDS job. the DDS driver 18 reads die 
conespionding script file 5d and generates a StartUst 
MainUst. and EndList of script records. The StartUst con- 
tains the above STAFT commands, the EndList contains the 
65 above END commands, and the MainUst contains the 
remaining script commands in-between. Each list contains 
only those commands where the node name matches tfie 
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System Name 82 stored in the script record. In the example 
script file of FIG. 5, the script lists generated by the DDS 16 
rumung oo the JDED node will contain only those com- 
mands where the System Name 82 Is JDED. 

To initialize the DDS 16 program, the DDS driver 18 5 
executes the START commands stored in the StartList. Each 
STAin" command has an associated user dcAned pfxx:ediire 
called by the DDS driver 18. Once initialized, the DDS 
driver 18 executes the script commands stored in the Main- 
List in a continuous loop until the user ends the job. When 
ended, the DDS driver 18 executes the END commands 
stored in the EadLisL Each END command has an associ- 
ated user defined procedure called by the DDS driver 18. 

Continuing now to FIG. 8, shown is pseudo code executed 
by the DDS driver 18 to process a script list. The ScriptUst 
input parameter is selected irom StartList. Mainlist. or 
EndList A global variable FUcDataRec *DataRec stores a 
record read from a file. A local variable ScriptRec *CurRec 
stares a current script record, a local variable FileDataRec 
♦DataRcc stores a file record, and a local variable Integer i 
stores a record count The CurRcc is initialized with the first ^ 
record in the list and its corresponding Verb 84 command is 
executed. 

If the Verb 84 is START or END, then the user procedure 
stored in the first Value 90 of the script record 
(CurRccParaml) is executed by an inter-process call. As is 
well understood by those skilled in the art the DDS 16 
junning as an ind^ndent program makes an inter-process 
oonmuinication call to the user procedure 22 also running as 
an indq>endent program. Inter-process communications pro- 
vides maximum flexibility since the user can specify any 
user procedure in the script file without having to re-compile 
and link the DDS 16 program. 

If the Verb 84 is READ, then the FUe Reader 20 reads a 
record 34 from the file specified in the first Value 9# <^ die 35 
script record (CurReci*araml). The record is stored in the 
global variable DataRec. If the Verb 84 is WRITE, then the 
record stored in DataRec is written to the file specified in the 
first Value 90 of the script record <CurRecJ>araml). If 
writing to a data conununications queue (DCQ). then the ^ 
second Value 92 of the script record (CurRec.Param2), 
which stores the name of the destination data queue at the 
remote node, is passed as the second parameter to the 
WriteRecord naethod. 

If the Verb 84 is PROC. then the user defined record 45 
procedure 22 stored in die first Value 90 of the script record 
(CurRec.Paraml) is executed by an inter-process call. 
Again, calling the record processor 22 using inter-process 
communications allows die user to modify operation of the 
DDS program without having to re-compile and re-link. The 50 
record processor 22 processes the file record stored in 
DataRec and returns a modified record 36. A NULL record 
returned by the record processor 22 Indicates that die user 
intends to omit the record from the synchronizing process. 

After processing the current script record, if the Col- 55 
lectHistory flag has been set by the user, the scr^t record 
CurRcc is written to the job d^^ file 4Z The record counter 
i is incremented, and the next scr^ record is read from the 
list and stored in CurRec. If CurRcc is NULL indicating that 
the end of the list has been readied, dien control is returned 60 
to the main method 110 of FIG. 7 which continues to process 
the MainList until the user terminates the job. When the job 
is terminated, the DDS driver 18 processes the EndList. Lc., 
it calls all of the user defined termination procedures asso- 
ciated with the END commands in the scr^ file. ^ 

Having described a preferred embodiment of the present 
invention, those skilled in the art will recognize that many 
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changes in form and details and widely differing embodi- 
ments and applications of the invention will suggest them- 
selves without dq)arting from the scope of the present 
invention, as defined by the following claims. The disclo- 
sures and the description herein are intended to be illustra- 
tive and are not in any sense limiting of the invention, as 
defined in scope by the foUowing claims. 
What is claimed is: 

1. In a distributed data computer network system com- 
prised of multiple nodes and interconnected for file data 
communications wherein each node has a data processor 
connected to a non-volatUe storage device for storing file 
data and further connected to a random access memory for 
storing and executing user applications, a distributed data 
synchronizer for synchronizing the file data across the 
multiple nodes comprising: 

(a) an application program executing within a first process of 
a local node, wherein the application program creates at 
least one local data record; 

(b) a file data reader, executing within a second process of 
the local node, for reading the at least one local data 
record; 

(c) a local data record process, responsive to each local data 
record read in step (b), for processing each local data 
record read in step (b) according to a first user defined 
criteria to generate a modified local data record for each 
local data record read in step (b); 

(d) an output process interfaced to a communication process 
for transferring each modified local data record generated 
in step (c) to a remote data processor at a remote node; 

(e) a renoote input process, executing within the remote node 
and interfaced to a communication process in the remote 
node for receiving each data record transferred in step (d); 

(0 a remote data record process, responsive to each remote 
data record received in step (e). for processing each 
remote data record received in stq> (e) according to a 
second user defined criteria to generate a modified remote 
data record for each remote data record received in step 
(e); and 

(g) a file data writer for writing each modified renoote data 
record generated in step (f) to the remote node. 

2. The distributed data synchronizer as recited In claim 1, 
wherein the local data record process is called through an 
inter-process communication system. 

3. The distributed data synchronizer as recited in claim 1, 
wherein the remote data record process is called throu^ an 
inter-process coromunicatioa system. 

4. The distributed data syncfaoronizcr as rrdtcd in claim 1. 
wherein: 

(a) the local data record process generates an omit indicator 
for indicating diat the local data record should be omitted; 
and 

(b) if (he omit indicator is active, then the modified local data 
record is not transferred to the remote data process of the 
remote node. 

5. The distributed data synchronizer as recited in daim 1. 
wherein: 

(a) the remote data record process generates an omit indi- 
cator for indicating that the remote data record should be 
omitted; and 

(b) if the omit indicator is active, then the nKxUfied remote 
data record is not written to the remote node. 

6. The distributed data synchronizer as recited in claim 1. 
further comprising a job status writer for periodically writ- 
ing a job stanis record to a job status file, the job status 
record comprising information on the status of the distrib- 
uted data synchronizer. 
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7. The distributed data syDchrooizer as recited in claim 1. (g) writing the modified remote data record to the remote 

further comprising a job detail writer for writing a job detail node. 

record to a job detail file, wherein: 14. The distributed data synchronizing method as recited 

(a> the job dctaU record is written concurrent with an in claim 13. wh^cin the distributed data synchronizing 

execuUon step of the distributed data synchronizer; and 3 method executes the step of processing the local data record 

(b) the j<^ dctaU record contains information related to the through an inicri^ocess communication sysicnL 

execution stq). ...... 15. The distributed data synchronizing method as recited 

g^The distributed data synchronize as reated m claim 6 ^^^^ ^ distributed data synchronizing 

ftirthercompnsinga jobsUtusdi^Uyerf^ ^^^^^ the remote data 

status record from the job status file and dispUyiBg die job ^^^^ inter^Less commui^cation system, 

status record on a computer screen connected to the local ..^^ * j ^ u 

data processes distributed dau synchronizing method as recited 

9. The distributed dau synchronizer as recited in claim 1, ^' whcrdn: 

further comprising a scr^jt process for processing a user P'^^^ gcntfates an omit indicator 

generated script file stored in die local node. mdicating that the local data record should be omitted 

10. The distributed data synchronizer as recited in claim synchronizing process; and 

9, wherein : 0>) ^ indicator is active, then the modified local data 

(a) the scrq>t file comprises a plurality of execution records; record is not transferred to the remote data processor of 

(b) each execution record c(»nprises a command and at least 20 remote node. 

one parameter associated with the command; 17- The distritnitcd data syDchioniziiig method as recited 

(c) the command selected from the group consisting of io claim 13, wherein: 

reading the local data record from the source file execut- (a) the step of processing the remote data record generates 

ing the local data record processor and outputting the an omit indicator for indicating that the remote data 

modified local data record to the communication process; 25 record should be omitted from the synchronizing process; 

and and 

(d) the parameter selected from the group consisting of a (b) if the omit indicator is active, then the modified remote 
source file nanae of the source file, a data recOTd processor data record is not written to the remote node. 

name of the local data record processor and a remote node jg. xhe distributed data synchronizing method as redtcd 

nain^of the remote node. . _ . in daim U. further comprising the step of periodically 

U wh«ciJ ^nchromza as recited m dami ^ ^^^^ ^ ^ ^^^^ ^ 

, ' \ ^ ^ ^ . record comprising information on the status of the distrib- 

0. Ac remote node funh« co^5es . scnp. process; sy»chronl2liig method. 

(b) the scnpi {voccss wittun the remote node processes a „ ^ *-.m_ 7TT* ^ ■ ■ ^ 

copy of the user generated script file; .^^^^ishfeuted data syndiromzing mrtbod as reated 

(c) eadi execution record within the user generated script ^!f^ ^ composing the step of writing a job 
file contains a system identifier whidi identifies a target to a job detail file, wherein: 

node that will execute the execution record; and ^ ^^'^ ^"^^ concurrent with an 

(d) the execution record is executed only if the system 40 ««=uUon step of the distributed data synchronizing 
identifier matches the corresponding node running the method; and 

distributed data synchronizer. ^ record contains information rcUtcd to die 

IZ The distributed daU synchronizer as rcdtcd in claim execution step. 

1, wherein the modified local data record is transfcncd to a disUributed data synchronizing method as recited 
plurality of remote daU processors of a plurality of remote 45 ^ further comprising die steps of: 

nodes. (^) reading the job status record from the job status file; 

13. In a distributed data computer network system com- and 

prised of multiple nodes and interconnected for file daUi (b) displaying the job status record on a counter screen 

communications wherein each node has a data pfoccssor connected to die local dau processor, 

connected to a non-voUtUe storage device for storing file 50 2I. The distributed daU synchronizing method as recited 

data and further connected to a random access memory for claim 13. further comprising die step ctf OTOccssing a user 

storing and executing user applications, a distributed daU ^cncr^ saipt file stored in the local node, 

syndtfonmng method for synchromzing the file data across The distributed daU synchronizing method as rtcited 

the multiple nodes compnsing the steps of: ^.j^ 21 wherein* 

('\^^^^<^^^^^'^^^f^^P^^^oft^ 55 (a)Aescriptfilecomprisesapluralityofexecutionrec«ds; 

(b) reading, within a second process of the local node, the ^^"'^^''^ "^f'* ^^''^ ^ ^''^^ 
local data record created in step (a); parameter associated with fte conmuuid; 

(c) processing the local data record according to a first user ^ command selected from die group consisting of 
defined criteria to generate a modified local data record; 60 ^ ^« 

(d) transferring the modified local data record to a itmote ^ local data record processor and outputting the 
data process of a remote node. modified local data record to the communication process; 

(e) receiving, within the remote node, die data record 

transferred in step (d); (d) die parameter selected from the group consisting of a 

(f) processing, within the remote node, the data record 65 sourccfilenameof the source file, a data record processor 
received in step (e) according to a second user defined name of the local data record processor and a rensote node 
criteria to generate a modified remote data record; and name of the remote node. 
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23. The distributed daU syachroiuzing method as recited 
in claim 13. further conq>rising the steps of: 

(a) copying the user generated script file to the remote node; 

(b) performing both the user generated script file in the local 
node concurrently with perforrning the copy of the user 5 
generated script file in the remote node; 

(c) associating a system ideotiiier with each execution 
record which identifies a target node that will execute the 
execution record; and 

(d) executing the execution record only if the system iden- lO 
tifier matches the corresponding node running the distrib- 
uted data synchronizer. 
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24. The distributed data synchronizing method as recited 
in claim 13. further comprising the step of transferring the 
modified local data record to a plurality of remote data 
processors of a plurality of remote nodes. 

25. The distributed data synchronizing method as recited 
in claim 13, wherein the steps comprised therein are 
executed continuously in order to monitor the source file and 
to transfer records stored in the source file to the remote 
nodes whenever the source file is modified by the user 
applications. 
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